/*
 * ORACLE PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.
 *
 *
 *
 *
 *
 *
 *
 *
 *
 *
 *
 *
 *
 *
 *
 *
 *
 *
 *
 *
 */

/*
 *
 *
 *
 *
 *
 * Written by Doug Lea with assistance from members of JCP JSR-166
 * Expert Group and released to the public domain, as explained at
 * http://creativecommons.org/publicdomain/zero/1.0/
 */

package java.util.concurrent.locks;

import java.util.concurrent.TimeUnit;
import java.util.Date;

import vjava.util.concurrent.*;

/**
 * {@code Condition} factors out the {@code Object} monitor methods (
 * {@link Object#wait() wait}, {@link Object#notify notify} and
 * {@link Object#notifyAll notifyAll}) into distinct objects to give the effect
 * of having multiple wait-sets per object, by combining them with the use of
 * arbitrary {@link Lock} implementations. Where a {@code Lock} replaces the use
 * of {@code synchronized} methods and statements, a {@code Condition} replaces
 * the use of the Object monitor methods.
 * 
 * <p>
 * Conditions (also known as <em>condition queues</em> or
 * <em>condition variables</em>) provide a means for one thread to suspend
 * execution (to &quot;wait&quot;) until notified by another thread that some
 * state condition may now be true. Because access to this shared state
 * information occurs in different threads, it must be protected, so a lock of
 * some form is associated with the condition. The key property that waiting for
 * a condition provides is that it <em>atomically</em> releases the associated
 * lock and suspends the current thread, just like {@code Object.wait}.
 * 
 * <p>
 * A {@code Condition} instance is intrinsically bound to a lock. To obtain a
 * {@code Condition} instance for a particular {@link Lock} instance use its
 * {@link Lock#newCondition newCondition()} method.
 * 
 * <p>
 * As an example, suppose we have a bounded buffer which supports {@code put}
 * and {@code take} methods. If a {@code take} is attempted on an empty buffer,
 * then the thread will block until an item becomes available; if a {@code put}
 * is attempted on a full buffer, then the thread will block until a space
 * becomes available. We would like to keep waiting {@code put} threads and
 * {@code take} threads in separate wait-sets so that we can use the
 * optimization of only notifying a single thread at a time when items or spaces
 * become available in the buffer. This can be achieved using two
 * {@link Condition} instances.
 * 
 * <pre>
 * class BoundedBuffer {
 *   <b>final Lock lock = new ReentrantLock();</b>
 *   final Condition notFull  = <b>lock.newCondition(); </b>
 *   final Condition notEmpty = <b>lock.newCondition(); </b>
 * 
 *   final Object[] items = new Object[100];
 *   int putptr, takeptr, count;
 * 
 *   public void put(Object x) throws InterruptedException {
 *     <b>lock.lock();
 *     try {</b>
 *       while (count == items.length)
 *         <b>notFull.await();</b>
 *       items[putptr] = x;
 *       if (++putptr == items.length) putptr = 0;
 *       ++count;
 *       <b>notEmpty.signal();</b>
 *     <b>} finally {
 *       lock.unlock();
 *     }</b>
 *   }
 * 
 *   public Object take() throws InterruptedException {
 *     <b>lock.lock();
 *     try {</b>
 *       while (count == 0)
 *         <b>notEmpty.await();</b>
 *       Object x = items[takeptr];
 *       if (++takeptr == items.length) takeptr = 0;
 *       --count;
 *       <b>notFull.signal();</b>
 *       return x;
 *     <b>} finally {
 *       lock.unlock();
 *     }</b>
 *   }
 * }
 * </pre>
 * 
 * (The {@link vjava.util.concurrent.ArrayBlockingQueue} class provides this
 * functionality, so there is no reason to implement this sample usage class.)
 * 
 * <p>
 * A {@code Condition} implementation can provide behavior and semantics that is
 * different from that of the {@code Object} monitor methods, such as guaranteed
 * ordering for notifications, or not requiring a lock to be held when
 * performing notifications. If an implementation provides such specialized
 * semantics then the implementation must document those semantics.
 * 
 * <p>
 * Note that {@code Condition} instances are just normal objects and can
 * themselves be used as the target in a {@code synchronized} statement, and can
 * have their own monitor {@link Object#wait wait} and {@link Object#notify
 * notification} methods invoked. Acquiring the monitor lock of a
 * {@code Condition} instance, or using its monitor methods, has no specified
 * relationship with acquiring the {@link Lock} associated with that
 * {@code Condition} or the use of its {@linkplain #await waiting} and
 * {@linkplain #signal signalling} methods. It is recommended that to avoid
 * confusion you never use {@code Condition} instances in this way, except
 * perhaps within their own implementation.
 * 
 * <p>
 * Except where noted, passing a {@code null} value for any parameter will
 * result in a {@link NullPointerException} being thrown.
 * 
 * <h3>Implementation Considerations</h3>
 * 
 * <p>
 * When waiting upon a {@code Condition}, a &quot;<em>spurious
 * wakeup</em>&quot; is permitted to occur, in general, as a concession to the
 * underlying platform semantics. This has little practical impact on most
 * application programs as a {@code Condition} should always be waited upon in a
 * loop, testing the state predicate that is being waited for. An implementation
 * is free to remove the possibility of spurious wakeups but it is recommended
 * that applications programmers always assume that they can occur and so always
 * wait in a loop.
 * 
 * <p>
 * The three forms of condition waiting (interruptible, non-interruptible, and
 * timed) may differ in their ease of implementation on some platforms and in
 * their performance characteristics. In particular, it may be difficult to
 * provide these features and maintain specific semantics such as ordering
 * guarantees. Further, the ability to interrupt the actual suspension of the
 * thread may not always be feasible to implement on all platforms.
 * 
 * <p>
 * Consequently, an implementation is not required to define exactly the same
 * guarantees or semantics for all three forms of waiting, nor is it required to
 * support interruption of the actual suspension of the thread.
 * 
 * <p>
 * An implementation is required to clearly document the semantics and
 * guarantees provided by each of the waiting methods, and when an
 * implementation does support interruption of thread suspension then it must
 * obey the interruption semantics as defined in this interface.
 * 
 * <p>
 * As interruption generally implies cancellation, and checks for interruption
 * are often infrequent, an implementation can favor responding to an interrupt
 * over normal method return. This is true even if it can be shown that the
 * interrupt occurred after another action that may have unblocked the thread.
 * An implementation should document this behavior.
 * 
 * @since 1.5
 * @author Doug Lea
 */
public interface Condition {

	/**
	 * Causes the current thread to wait until it is signalled or
	 * {@linkplain Thread#interrupt interrupted}.
	 * 
	 * <p>
	 * The lock associated with this {@code Condition} is atomically released
	 * and the current thread becomes disabled for thread scheduling purposes
	 * and lies dormant until <em>one</em> of four things happens:
	 * <ul>
	 * <li>Some other thread invokes the {@link #signal} method for this
	 * {@code Condition} and the current thread happens to be chosen as the
	 * thread to be awakened; or
	 * <li>Some other thread invokes the {@link #signalAll} method for this
	 * {@code Condition}; or
	 * <li>Some other thread {@linkplain Thread#interrupt interrupts} the
	 * current thread, and interruption of thread suspension is supported; or
	 * <li>A &quot;<em>spurious wakeup</em>&quot; occurs.
	 * </ul>
	 * 
	 * <p>
	 * 
	 * 造成当前线程在接到信号或被中断之前一直处于等待状态。
	 * <p>
	 * 与此 Condition 相关的锁以原子方式释放，并且出于线程调度的目的，将禁用当前线程，且在发生以下四种情况之一
	 * 以前，当前线程将一直处于休眠状态：
	 * <ul>
	 * <li>其他某个线程调用此 Condition 的 signal() 方法，并且碰巧将当前线程选为被唤醒的线程；或者
	 * <li>其他某个线程调用此 Condition 的 signalAll() 方法；或者
	 * <li>其他某个线程中断当前线程，且支持中断线程的挂起；或者
	 * <li>发生“虚假唤醒”
	 * </ul>
	 * 
	 * <p>
	 * In all cases, before this method can return the current thread must
	 * re-acquire the lock associated with this condition. When the thread
	 * returns it is <em>guaranteed</em> to hold this lock.
	 * 
	 * <p>
	 * If the current thread:
	 * <ul>
	 * <li>has its interrupted status set on entry to this method; or
	 * <li>is {@linkplain Thread#interrupt interrupted} while waiting and
	 * interruption of thread suspension is supported,
	 * </ul>
	 * then {@link InterruptedException} is thrown and the current thread's
	 * interrupted status is cleared. It is not specified, in the first case,
	 * whether or not the test for interruption occurs before the lock is
	 * released.
	 * 
	 * <p>
	 * <b>Implementation Considerations</b>
	 * 
	 * <p>
	 * The current thread is assumed to hold the lock associated with this
	 * {@code Condition} when this method is called. It is up to the
	 * implementation to determine if this is the case and if not, how to
	 * respond. Typically, an exception will be thrown (such as
	 * {@link IllegalMonitorStateException}) and the implementation must
	 * document that fact.
	 * 
	 * <p>
	 * An implementation can favor responding to an interrupt over normal method
	 * return in response to a signal. In that case the implementation must
	 * ensure that the signal is redirected to another waiting thread, if there
	 * is one.
	 * 
	 * @throws InterruptedException
	 *             if the current thread is interrupted (and interruption of
	 *             thread suspension is supported)
	 * 
	 */
	void await() throws InterruptedException;

	/**
	 * Causes the current thread to wait until it is signalled.
	 * <p>
	 * 线程等待并且忽视中断。
	 * <p>
	 * The lock associated with this condition is atomically released and the
	 * current thread becomes disabled for thread scheduling purposes and lies
	 * dormant until <em>one</em> of three things happens:
	 * <ul>
	 * <li>Some other thread invokes the {@link #signal} method for this
	 * {@code Condition} and the current thread happens to be chosen as the
	 * thread to be awakened; or
	 * <li>Some other thread invokes the {@link #signalAll} method for this
	 * {@code Condition}; or
	 * <li>A &quot;<em>spurious wakeup</em>&quot; occurs.
	 * </ul>
	 * 
	 * <p>
	 * In all cases, before this method can return the current thread must
	 * re-acquire the lock associated with this condition. When the thread
	 * returns it is <em>guaranteed</em> to hold this lock.
	 * 
	 * <p>
	 * If the current thread's interrupted status is set when it enters this
	 * method, or it is {@linkplain Thread#interrupt interrupted} while waiting,
	 * it will continue to wait until signalled. When it finally returns from
	 * this method its interrupted status will still be set.
	 * 
	 * <p>
	 * <b>Implementation Considerations</b>
	 * 
	 * <p>
	 * The current thread is assumed to hold the lock associated with this
	 * {@code Condition} when this method is called. It is up to the
	 * implementation to determine if this is the case and if not, how to
	 * respond. Typically, an exception will be thrown (such as
	 * {@link IllegalMonitorStateException}) and the implementation must
	 * document that fact.
	 */
	void awaitUninterruptibly();

	/**
	 * Causes the current thread to wait until it is signalled or interrupted,
	 * or the specified waiting time elapses.
	 * 
	 * <p>
	 * The lock associated with this condition is atomically released and the
	 * current thread becomes disabled for thread scheduling purposes and lies
	 * dormant until <em>one</em> of five things happens:
	 * <ul>
	 * <li>Some other thread invokes the {@link #signal} method for this
	 * {@code Condition} and the current thread happens to be chosen as the
	 * thread to be awakened; or
	 * <li>Some other thread invokes the {@link #signalAll} method for this
	 * {@code Condition}; or
	 * <li>Some other thread {@linkplain Thread#interrupt interrupts} the
	 * current thread, and interruption of thread suspension is supported; or
	 * <li>The specified waiting time elapses; or
	 * <li>A &quot;<em>spurious wakeup</em>&quot; occurs.
	 * </ul>
	 * 
	 * <p>
	 * In all cases, before this method can return the current thread must
	 * re-acquire the lock associated with this condition. When the thread
	 * returns it is <em>guaranteed</em> to hold this lock.
	 * 
	 * <p>
	 * If the current thread:
	 * <ul>
	 * <li>has its interrupted status set on entry to this method; or
	 * <li>is {@linkplain Thread#interrupt interrupted} while waiting and
	 * interruption of thread suspension is supported,
	 * </ul>
	 * then {@link InterruptedException} is thrown and the current thread's
	 * interrupted status is cleared. It is not specified, in the first case,
	 * whether or not the test for interruption occurs before the lock is
	 * released.
	 * 
	 * <p>
	 * The method returns an estimate of the number of nanoseconds remaining to
	 * wait given the supplied {@code nanosTimeout} value upon return, or a
	 * value less than or equal to zero if it timed out. This value can be used
	 * to determine whether and how long to re-wait in cases where the wait
	 * returns but an awaited condition still does not hold. Typical uses of
	 * this method take the following form:
	 * 
	 * <pre>
	 * {@code
	 * boolean aMethod(long timeout, TimeUnit unit) {
	 *   long nanos = unit.toNanos(timeout);
	 *   lock.lock();
	 *   try {
	 *     while (!conditionBeingWaitedFor()) {
	 *       if (nanos <= 0L)
	 *         return false;
	 *       nanos = theCondition.awaitNanos(nanos);
	 *     }
	 *     // ...
	 *   } finally {
	 *     lock.unlock();
	 *   }
	 * }}
	 * </pre>
	 * 
	 * <p>
	 * Design note: This method requires a nanosecond argument so as to avoid
	 * truncation errors in reporting remaining times. Such precision loss would
	 * make it difficult for programmers to ensure that total waiting times are
	 * not systematically shorter than specified when re-waits occur.
	 * 
	 * <p>
	 * <b>Implementation Considerations</b>
	 * 
	 * <p>
	 * The current thread is assumed to hold the lock associated with this
	 * {@code Condition} when this method is called. It is up to the
	 * implementation to determine if this is the case and if not, how to
	 * respond. Typically, an exception will be thrown (such as
	 * {@link IllegalMonitorStateException}) and the implementation must
	 * document that fact.
	 * 
	 * <p>
	 * An implementation can favor responding to an interrupt over normal method
	 * return in response to a signal, or over indicating the elapse of the
	 * specified waiting time. In either case the implementation must ensure
	 * that the signal is redirected to another waiting thread, if there is one.
	 * 
	 * @param nanosTimeout
	 *            the maximum time to wait, in nanoseconds
	 * @return an estimate of the {@code nanosTimeout} value minus the time
	 *         spent waiting upon return from this method. A positive value may
	 *         be used as the argument to a subsequent call to this method to
	 *         finish waiting out the desired time. A value less than or equal
	 *         to zero indicates that no time remains.
	 * @throws InterruptedException
	 *             if the current thread is interrupted (and interruption of
	 *             thread suspension is supported)
	 */
	long awaitNanos(long nanosTimeout) throws InterruptedException;

	/**
	 * Causes the current thread to wait until it is signalled or interrupted,
	 * or the specified waiting time elapses. This method is behaviorally
	 * equivalent to:<br>
	 * 
	 * <pre>
	 * awaitNanos(unit.toNanos(time)) &gt; 0
	 * </pre>
	 * 
	 * @param time
	 *            the maximum time to wait
	 * @param unit
	 *            the time unit of the {@code time} argument
	 * @return {@code false} if the waiting time detectably elapsed before
	 *         return from the method, else {@code true}
	 * @throws InterruptedException
	 *             if the current thread is interrupted (and interruption of
	 *             thread suspension is supported)
	 */
	boolean await(long time, TimeUnit unit) throws InterruptedException;

	/**
	 * Causes the current thread to wait until it is signalled or interrupted,
	 * or the specified deadline elapses.
	 * 
	 * <p>
	 * The lock associated with this condition is atomically released and the
	 * current thread becomes disabled for thread scheduling purposes and lies
	 * dormant until <em>one</em> of five things happens:
	 * <ul>
	 * <li>Some other thread invokes the {@link #signal} method for this
	 * {@code Condition} and the current thread happens to be chosen as the
	 * thread to be awakened; or
	 * <li>Some other thread invokes the {@link #signalAll} method for this
	 * {@code Condition}; or
	 * <li>Some other thread {@linkplain Thread#interrupt interrupts} the
	 * current thread, and interruption of thread suspension is supported; or
	 * <li>The specified deadline elapses; or
	 * <li>A &quot;<em>spurious wakeup</em>&quot; occurs.
	 * </ul>
	 * 
	 * <p>
	 * In all cases, before this method can return the current thread must
	 * re-acquire the lock associated with this condition. When the thread
	 * returns it is <em>guaranteed</em> to hold this lock.
	 * 
	 * 
	 * <p>
	 * If the current thread:
	 * <ul>
	 * <li>has its interrupted status set on entry to this method; or
	 * <li>is {@linkplain Thread#interrupt interrupted} while waiting and
	 * interruption of thread suspension is supported,
	 * </ul>
	 * then {@link InterruptedException} is thrown and the current thread's
	 * interrupted status is cleared. It is not specified, in the first case,
	 * whether or not the test for interruption occurs before the lock is
	 * released.
	 * 
	 * 
	 * <p>
	 * The return value indicates whether the deadline has elapsed, which can be
	 * used as follows:
	 * 
	 * <pre>
	 * {@code
	 * boolean aMethod(Date deadline) {
	 *   boolean stillWaiting = true;
	 *   lock.lock();
	 *   try {
	 *     while (!conditionBeingWaitedFor()) {
	 *       if (!stillWaiting)
	 *         return false;
	 *       stillWaiting = theCondition.awaitUntil(deadline);
	 *     }
	 *     // ...
	 *   } finally {
	 *     lock.unlock();
	 *   }
	 * }}
	 * </pre>
	 * 
	 * <p>
	 * <b>Implementation Considerations</b>
	 * 
	 * <p>
	 * The current thread is assumed to hold the lock associated with this
	 * {@code Condition} when this method is called. It is up to the
	 * implementation to determine if this is the case and if not, how to
	 * respond. Typically, an exception will be thrown (such as
	 * {@link IllegalMonitorStateException}) and the implementation must
	 * document that fact.
	 * 
	 * <p>
	 * An implementation can favor responding to an interrupt over normal method
	 * return in response to a signal, or over indicating the passing of the
	 * specified deadline. In either case the implementation must ensure that
	 * the signal is redirected to another waiting thread, if there is one.
	 * 
	 * @param deadline
	 *            the absolute time to wait until
	 * @return {@code false} if the deadline has elapsed upon return, else
	 *         {@code true}
	 * @throws InterruptedException
	 *             if the current thread is interrupted (and interruption of
	 *             thread suspension is supported)
	 */
	boolean awaitUntil(Date deadline) throws InterruptedException;

	/**
	 * Wakes up one waiting thread.
	 * <p>
	 * 只会唤醒一个线程，这个线程必须重新获取关联的锁。
	 * <p>
	 * If any threads are waiting on this condition then one is selected for
	 * waking up. That thread must then re-acquire the lock before returning
	 * from {@code await}.
	 * 
	 * <p>
	 * <b>Implementation Considerations</b>
	 * 
	 * <p>
	 * An implementation may (and typically does) require that the current
	 * thread hold the lock associated with this {@code Condition} when this
	 * method is called. Implementations must document this precondition and any
	 * actions taken if the lock is not held. Typically, an exception such as
	 * {@link IllegalMonitorStateException} will be thrown.
	 */
	void signal();

	/**
	 * Wakes up all waiting threads.
	 * <p>
	 * 唤醒所有等待的线程，所有线程都会尝试去获取相关联的锁。根据锁的类型，唤醒的线程数量不定。
	 * <p>
	 * If any threads are waiting on this condition then they are all woken up.
	 * Each thread must re-acquire the lock before it can return from
	 * {@code await}.
	 * 
	 * <p>
	 * <b>Implementation Considerations</b>
	 * 
	 * <p>
	 * An implementation may (and typically does) require that the current
	 * thread hold the lock associated with this {@code Condition} when this
	 * method is called. Implementations must document this precondition and any
	 * actions taken if the lock is not held. Typically, an exception such as
	 * {@link IllegalMonitorStateException} will be thrown.
	 */
	void signalAll();
}
